\subsection{Les objectifs}
Avant de mettre en place un protocole de paiement avec carte bancaire, il convient d'identifier les critères à respecter pour assurer un certain niveau de sécurité au cours de cette transaction. Nous avons ainsi déterminé cinq critères c:
\begin{enumerate}
\item \textbf{Authentification mutuelle :} le client doit pouvoir authentifier le commerçant. Respectivement, le commerçant doit pouvoir authentifier le client.
\item \textbf{Non répudiation :} Ni le client, ni le commerçant ne doit pouvoir renier la transaction.
\item \textbf{Validité de la transaction :} La banque qui va mettre en œuvre le paiement doit pouvoir vérifier que le client et le commerçant sont bien d'accord sur la transaction.
\item \textbf{Anonymat bancaire :} Le commerçant ne doit pas pouvoir connaître les identifiants bancaires du client.
\item \textbf{Anonymat des achats :} La banque n'a pas à savoir ce que le client achète.
\end{enumerate}

\subsection{Schéma global}

\begin{figure}[h!]
\centering
\includegraphics[scale=0.5]{./Images/global.eps}
\caption{Schéma de l'architecture du projet}
\label{fig:objet}
\end{figure} 
\begin{itemize}
\item étape 1 : Validation du devis par la boutique
\item étape 2 : Établissement d'une connexion terminal - carte
\item étape 3 : Vérification du code pin
\item étape 4 : Si l'authentification de la carte est bonne, alors envoie du devis signé par le terminal
\item étape 5 : La carte reçoit le devis signé, rajoute des informations (sa clé publique et son identifiant bancaire), signe le tout à son tour et renvoie tout au terminal.
\item étape 6 : Établissement d'une connexion terminal-banque 
\item étape 7 : Envoi d'un requête https de la boutique à la banque
\item étape 8 : Exécution des opérations sur les bases de données sur la banque
\item étape 9 : Réponse de la banque à la boutique si cela s'est bien passé ou non
\end{itemize}

Nous avons supposé le lien Carte-Terminal sûr et ce n'est qu'un échange de signature. Les opérations que nous jugeons critiques sont l'écriture dans la base de données car si une personne malveillant veut faire des opérations bancaires cela mettrait le système à plat. La solution trouvée est de ne pas inscrire les requêtes dans notre applet  Terminal, seul le serveur doit les connaitre. Autre problème de ce type le modification du montant, le montant confirmé ne doit pas être modifier en cours de route. La boutique pourrait changer le montant de la transaction à tout moment si on ne signait pas le devis par la carte et la boutique.


\subsection{Les acteurs de la transaction}
Nous avons considérés uniquement trois principales entités pour la mise en œuvre de notre protocole de transaction par carte à puce :
\begin{itemize}
\item La carte et son détenteur (le client). Celle-ci permettra de vérifier l'identité de son détenteur tout en liant celui-ci à un compte bancaire.
\item Le terminal. Celui-ci devra authentifier la carte et son porteur et initier la communication vers la banque.
\item La banque. Dans notre cas, celle-ci est commune au client et au commerçant. Elle devra vérifier l'existence des comptes. Elle devra également s'assurer que le compte du client est suffisamment approvisionné.
\end{itemize}

%FAIRE UN DIAGRAMME DE SEQUENCE
%
%
%\begin{figure}[h!]
%\centering
%\includegraphics[scale=0.5]{./Images/objet.eps}
%\caption{Classes}
%\label{fig:objet}
%\end{figure}
%
%\pagebreak
\subsection{Structure de la base de données de la banque}

\begin{figure}[h!]
\centering
\includegraphics[scale=0.75]{./Images/bd.eps}
\caption{Structure et requêtes utilisées}
\label{fig:bd}
\end{figure}

Dans l'image ci-dessus on a souligné d'un trait fin les clés primaires et d'un trait épais les clés étrangère. On aurait pu stocké dans la table compte les clés publique de la carte de paiement, afin d'avoir une donnée en moins à transmettre au serveur et de simplifier la vérification. Ensuite il y a la liste des principales requêtes nécessaire aux deux applications que nous voulions implémenter. La base qui nous utilisons est une base PostgreSql.


\pagebreak
%\subsection{Génération des clés}
%
%\paragraph{BasicCard} Blabla
%
%\paragraph{Java} Nous avons fait une programme à part pour générer les clés pour nous permettre les tests. Les clés sont stockés dans deux fichiers l'un pour la clé publique et l'autre la clé privée. Lors de la création de l'objet Boutique nous récupérons les clés enregistrées.

\subsection{Consultation}

\begin{figure}[h!]
\centering
\includegraphics[scale=0.8]{./Images/consult.eps}
\caption{Diagramme de séquence de consultation en local}
\label{fig:paie}
\end{figure}

Ce schéma résume notre implémentation. Nous avons eu quelques problèmes avec la mise en place du serveur et le manque de temps nous a contraint à n'implémenter qu'une version avec une base de données locale. Ceci décrit l'étape de test du programme avant l'installation du serveur. \\

Une version disposant d'un serveur aurait envoyé par exemple après l'authentification de la carte une requête https au serveur et toute la partie concernant la base de données aurait été traiter sur le serveur. L'applet JAVA n'aurait pas eu accès directement à la base qui est une partie critique du serveur et dont l'accès doit être au maximum restreint





\pagebreak

\subsection{Paiement}

\begin{figure}[h!]
\centering
\includegraphics[scale=0.8]{./Images/Paiement.eps}
\caption{Diagramme de séquence d'un paiement en local}
\label{fig:paie}
\end{figure}


Tout comme la version consultation de notre programme, il manque la partie serveur pour que ce soit terminer.\\

Le paiement nécessite l'authentification de la carte ainsi que sa signature. Les étapes de vérification des signatures ne sont pas écrites sur le schéma car il est impossible de vérifier la signature faite par la carte (ceci est détaillé dans la conclusion Partie \ref{sec:Conclusion}) et il est sans intérêt de vérifier celle crée par le terminal dans celui-ci.\\

Nous n'avons pas géré les différents événements du type arrachage de la carte en cours de transaction, coupure de connexion serveur et bien d'autres encore comme initialement prévu. 


